RESTAURANT AUTOMATION SYSTEM 



FIELD OF THE INVENTION 
The present invention relates to automated restaurant 
management systems, and to the automation of order taking, 
bill paying and other services, 

BACKGROUND OF THE INVENTION 
Many restaurants run on thin profit margins. 
Instituting operational efficiencies in a restaurant can 
have an enormous impact on the bottom line. Hence, 
instituting efficiencies are always needed to increase the 
revenue per seating, and/or to increase the number of 
sittings per day. In addition, certain efficiencies and/or 
customer services produce the ability to attract and retain 
more patrons. There has been no shortage of proposals to 
make the backend (kitchen, waiter, inventory control, 
supply ordering, etc.) operations of restaurants more 
efficient. More recently, the use of small, powerful 
computing devices, has been proposed to create efficiencies 
in the front-end operations (customer interfacing) . 
However, to be adapted for restaurants, more efficient 
operational solutions must be inexpensive, and have a short 
return on investment (ROI) . In the restaurant business, a 



large capital investment generally presents a barrier to 
the adoption of otherwise beneficial solutions. In 
addition, the cost of a proposed improvement must be offset 
by the operational efficiencies it provides. Further, for 
5 restaurant customers, both ease-of-use and elegance are 
significant success factors. Any new restaurant system 
must not present a learning burden to the diner, but should 
be intuitive, allowing the diner to succeed in using it the 
first time. 

10 

It has been proposed to improve the efficiencies in 
restaurant operations by permitting waiters to 
electronically transmit orders to the kitchen. Indeed, 
some systems permit the customer or diner to directly send 
15 orders to the kitchen. 



For example, U.S. Patent No. 6,425,524 to Pentel 
describes a remote ordering system using hand-held devices 
such as at 112, in Fig. 12a, which transmit orders to an 
20 order station. The hand-held device utilizes key pad entry 
for placing an order, which may be displayed on an LCD 
screen before sending the order to the order station. The 
menu is presented on a separate apparatus called a display 
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device which displays the ordering numbers associated with 
different food orders. It may also have a screen 
displaying the order message received. In its broadest 
application, the restaurateur may also post a pre-viewing 
5 menu on a website, and the components of the had-held 
device imbedded in a cell phone. Though the patent 
describes an "order ready" signally means, and a 
"change/recall" order means, there is no message for when 
the food preparation has started. A customer order number 

10 may be sent to the hand-held device, but there is no means 
described for assigning a table ID. Pentel also discloses 
an ordering system for a drive-thru restaurant (Figs 1, 1a, 
and 2) wherein the transmission from the hand-held device 
12 may be a short range line-of-sight remote control device 

15 transmitting to a drive-up display menu. The hand-held 
devices have key pads which are impractical in a 
restaurant/dining environment full of drips and crumbs 
which can jam the keys. No graphic representation of the 
food items available is presented on the screen. Nor are 

20 there pop-up display of food offerings to explore further 
and further the details of the menu. 
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U.S. Patent 5,838,798 to Smith discloses a hand-held 
portable device for placing an order to a server, and then 
to a kitchen terminal. However, these devices are intended 
to be operated by the waiter, hence, the level of detail, 
5 comprising graphic representations of the food offering 
need be minimal, as the waiter knows the menu. 

TouchPak sells a system, called an entertainment 
portal. Customers waiting to be seated may be presented 
10 with the device, from which they can pre-view a menu, 
preorder, surf the Internet and receive a table ready 
signal . 

In a restaurant where customers are seated before 
15 ordering, an interactive system has been proposed, 

according to which an interactive table display must be 
used by each diner at the table. These systems vary from 
the traditional arrangement wherein each diner is permitted 
his/her own menu, to consult individually. Some of the 
20 systems proposed for increased efficiency require a change 
in operational steps, or interactive sequences of 
conventional dining, and thereby present an adaptability 
barrier to widespread customer acceptance. What is needed 



is a solution that is familiar in its presentation and yet, 
substantially rich in underlying functionality. 

Despite the plethora of new restaurant management 
5 system solutions, the customer's experience in a restaurant 
has hardly changed through the years. In a traditional 
restaurant, a large percentage of time is actually spent 
waiting for the waiter, rather than eating. First, one 
must wait for the waiter to take an order. The length of 

10 this waiting period bears no relationship to the hunger or 
desires of the customer. Next, one must interrupt eating 
while waiting for the opportunity to catch the waiter's 
attention if a water or soda refill, or other adjunct item, 
such as a relish or dressing, is necessary. Finally, among 

15 other services, one must wait for the waiter to provide a 
check and then, wait again, for him to return with the 
receipt. Not only does this impose suffrage on the 
customer in terms of waiting, but it may also preclude 
synchronization of the various courses of the meal. Since 

20 up to half the time spent in the restaurant may be spent 
waiting for the waiter, the restaurant also loses revenue, 
as the table cannot be turned for the next customer. 
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During an evening, up to an entire table service may be 
lost . 

The present invention not only provides increased 
5 efficiencies in the operation of the restaurant, but 

provides vast enhancements in the menu, ease of payment, 
information and/or entertainment provided to the customer, 
with no loss in comfort or elegance. In a preferred 
embodiment, the present invention provides a 

10 personalization/benefits system customized to the dining 
patterns of each diner. The present invention hence 
presents a win-win solution for the restaurateur and the 
diner. Perhaps most significantly, the present invention 
eliminates or substantially reduces the need for 

15 waiters/cashiers/hostesses thereby introducing a novel 
operational model for the restaurant industry that can 
result in favorable cash flow economics. 

SUMMARY OF THE INVENTION 
20 In its preferred embodiment, the present invention 

provides a restaurant automation system which comprises at 
least an Automated Ordering System (AOS) component system, 
and may also include at least one of following component 
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systems; the Waiter Call System (WCS) , the Reception 
Management System (RMS), and the Customer Personalization 
System (CPS) ♦ 

5 The Automated Ordering System 

The Automated Ordering System (AOS) is the core 
component of the Restaurant Automation System and consists 
of the AOS function on the RAS compute server, the E-Menu, 
and, optionally, the Payment Station, as its main 

10 components. The E-Menu represents a significant evolution 
in restaurant service technology and distinguishes the AOS 
and RAS of the present invention from other suggested 
automation systems. The E-Menu is a low-cost interactive 
device that provides users with a platform for the display 

15 of rich content information provided by a restaurant 

compute server. Whereas many applications for the E-Menu 
are envisioned, in the current embodiment, the E-Menu is 
used directly by individual restaurant diners (as opposed 
to waiters or cashiers) . The diners may use the E-menu to 

20 access, text, graphical, video, audio information relating 
to the restaurant's menu, as well as other relevant 
information regarding the chef, restaurant background, live 
kitchen video , etc. Far more information can be displayed 



on an E-menu than a paper menu or blackboard* It also 
provides an interface through which the diners may directly 
place food orders with the kitchen, receive status on order 
preparation, direct the generation and payment of bills, 
5 access the Internet, etc. 

The E-Menu represents an evolution of the traditional 
hardcopy menu and provides a number of usability and 
economic benefits. At the same time, the E-Menu is 
10 designed to be gracefully and to be easily adopted by the 
general public because of its similarity in basic 
operational sequence to the traditional menu and human 
interface design. 

15 The AOS provides several benefits to both the customer 

and the restaurant industry. First, it removes customer 
dependency upon the waiter. The E-Menu, when used as part 
of the overall Automated Ordering System, grants full 
control of the dining experience from information access, 

20 bill payment, meal course timing, entertainment, etc. 
directly to the customer. The E-menu also provides 
customers with richer information content than a waiter can 
provide, and also allows dining times to be more controlled 



and predictable. This allows customers to dine out in 
situations where they otherwise would not have because of 
perceived time constraints. This leads to a simultaneous 
benefit for the restaurant industry. 

5 Second, since the AOS and E-Menu provide rich content 

information on the meals (photos, ingredients, preparation, 
nutrition, specials, etc.) in a dynamic format, it makes it 
easy for customers to be more educated about what they are 
ordering. For example, photos provide a clear depiction of 
10 what the meal will look like prior to ordering. This 
eliminates unexpected surprises regarding portion size, 
appearance, etc., thereby increasing satisfaction with the 
dining experience. This thereby provides obvious benefits 
to the restaurant industry. 

15 Third, the E-Menu and the Restaurant Automation System 

in general, significantly reduce the amount of time diners 
waste in a restaurant waiting for services and items 
because of waiter/cashier dependency. This allows the 
restaurant to turn the table more quickly resulting in a 

20 greater number of table services, which in turn, results in 
greater revenue. 
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Fourth, the E-Menu serves as a dynamic advertising 
medium through which the restaurant industry may derive an 
additional revenue stream. 

Fifth, the AOS increases the restaurant's ability to 
5 quickly adapt to changing tastes, styles, specials, etc. by 
providing a menu platform that can be updated dynamically. 
Specifically, once menu changes have been made in the RAS 
compute server, all the E-menus have immediate access to 
the updated information. In addition, the entire style, 
10 motif or design of the restaurant may be adjusted rapidly 
by changes made at the server. 

The E-Menu, may be approximately the size of a 
traditional menu. It can present the menu contents in a 
familiar way on a large touch sensitive LCD display with 

15 the additional functionality of presenting rich content 
information related to the restaurant, chef, meals, etc. 
The E-Menu may also provide a web browser or similar 
platform by means by which diners can access a restaurant's 
web server for web pages that define the restaurant's menu, 

20 specials, etc. The restaurant's web server (running on the 
RAS compute server) accesses a (preferably) broadband 
Internet connection and provides a proxy server function 
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such that, when permitted, diners may access the Internet 
from their E-Menu. 

In an alternative embodiment, the E-Menu may be a 
5 light weight display appliance in terms of processing 

requirements, power requirements, software, cost, etc. that 
simply displays pre-processed graphical data from the 
restaurant's RAS compute server. 

The E-Menu has a standard wireless network interface 
10 and communicates over a standard wireless Local Area 

Network (LAN) to a Restaurant Automation System compute 
server (compute device) . The RAS compute server hosts the 
central intelligence and functions of the overall RAS 
system within a RAS equipped restaurant. The AOS function 
15 is one such function. 

The Automated Ordering System also automates the 
process of bill payment and reduces dependence on the 
waiter The service staff will still be needed for cash 
payment) . At any time during the dining process, a 
20 customer can request to have his table order tallied and 
sent to a Payment Station at which he may make payment. 
Various billing schemes per table can also be facilitated. 
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The Waiter Call System 

The Waiter Call System (WCS) provides customers with 
an efficient means to attract the attention of the common 
service staff, and to provide an indication of what they 
5 desire. In a preferred embodiment, the system utilizes 
various colored lights in an appropriately decorative 
tabletop display, called a Table Call Unit, to convey the 
message. If desired, such as when a line-of -sight viewing 
of the Table Call Unit is not feasible, a more centrally 

10 located Call Status Display, detailing the messages from a 
number of tables, can be used. Any member of the common 
service personnel pool can attend to the request. The 
specific color or light pattern of the request can identify 
what is requested. After the request has been satisfied, 

15 the WCS Function of the RAS server stores information 

related to the request and its service in the common data 
store for Quality of Service (QOS) gauging and reporting. 

Diners using the Waiter Call System do not have to 
waste time catching the attention of a particular waiter. 
20 Instead, the WCS sends a clear signal that is visible to 
any member of the common service pool. Using the color of 
the signal to convey a basic message as to what is desired 
avoids the traditional waiter double-trip (waiter first 
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comes to ask what you want and then goes off again to get 
it). This saves time in two ways. First, as any member of 
the service staff that is available can satisfy the 
request, the time benefits of a multiple server queuing 
5 model are realized. Second, there is no longer a need to 
visually catch the attention of a specific waiter, as any 
member of the common service pool can readily see the 
visible light. 

The WCS and the RAS in general, prescribe a different 
approach to the traditional restaurant service operational 
model. Whereas the traditional restaurant assigns waiters 
to specific tables and areas, the Restaurant Automation 
System introduces the concept of a common pool of service 
personnel that service the entire restaurant. The model of 
the WCS is akin to the efficient single queue-multiple 
server system for service in such facilities as banks. 

The Reception Management System 
20 The Automated Ordering System function in the RAS 

compute server maintains information regarding the dining 
status at each table, such as what has been ordered 
(appetizer, main course, coffee, etc) , the time elapsed, 
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bill requested, etc. This information is fed to the 
Reception Management System (RMS) which determines the 
expected wait time for each table. This wait time may be 
displayed on a Reception Display in the reception area. 
5 Arriving customers can enter their names in lists, or 
queues, for tables of a specific size, based on this 
expected wait time information. 

The Reception Management System eliminates the need 
for human receptionists to guess, and, perhaps, to 
10 inaccurately estimate wait times for tables of various 
capacities . 

The RMS may also allow the service staff to accept 
call-in reservations and enter these reservations into the 

i o 

RMS's scheduling function via the Reservation Display. The 
15 RMS coordinates the scheduling of tables based on call-in 
reservations, walk- in customers who enter into queues, and 
expected table wait time information based on real-time 
dining status. 

The RMS may be set to calculate table wait times based 

20 on real time dining status information for the particular 

restaurant, and allocates tables based on input from the 

Reception Display and the Reservation Display. 
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The RMS may be used in conjunction with current 
systems used to call waiting customers, such as blinking 
drink coasters, and may also offer an optional restaurant 
mapping application that facilitates customer self-seating. 

5 

The Customer Personalization System 

The customer and restaurant intelligence of the 
Restaurant Automation System within a restaurant resides in 
the main RAS compute server. This server maintains the 

10 restaurant menu, chef information, restaurant history, 

hyperlinks to advertiser's website, table status, and other 
rich content and makes it available to the E-Menu devices, 
Reception Display, Kitchen Order Display, and other 
displays of the restaurant's RAS. The RAS compute server 

15 also maintains information on Internet web sites visited by 
diners (but may not have the capability of identifying who 
visited what site) , food-ordering patterns, dining times 
per table, throughout the day, etc. All this information 
can be used by the restaurant managers and by restaurant 

20 marketing organizations to develop systems and food 
products better suited for the restaurant industry. 
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The Service Management Function, one of the RAS common 
functions (described later) running on the RAS compute 
server, provides a means of regularly compiling information 
and sending it to the RAS Central Service Center where it 
may be reviewed by the Central Service Center personnel. 
Information from the data store of each restaurant's RAS 
Compute Server is automatically transmitted to the RAS 
Central Server located at the RAS Central Service Center 
via the Internet link or via a dial-up means. This allows 
the RAS Central Service Center personnel to identify trends 
and track performance and error statistics on each 
restaurant's RAS implementation. The intention of this 
"call-home" system is to allow the RAS Central Service 
personnel to proactively monitor the effectiveness of the 
Restaurant Automation System at each establishment and to 
proactively take action to upgrade or replace 
systems/components before failure. This alleviates the 
restaurateur from the burden of managing the RAS system 
thereby reducing costs and allowing him to focus on his 
primary business of food preparation and service. 

Another advantage to the collection of restaurant and 
customer intelligence on the RAS system is that it allows 
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personalization of services for specific diners based on 
patronage frequency and dining patterns. For example, if a 
specific diner frequents RAS equipped restaurants or shows 
a preference for kosher meals based on the information in 
the data store of the RAS Central Service Center server, 
the RAS system may apply discounts to his bill or may 
provide focused meal advertising, specials, or suggestions 
via the E-Menu platform. This collection of data 
essentially allows for the creation of an automated and 
customized "frequent diner" program for the restaurant 
industry. 



There are a number of RAS system functions common to 
the component systems. For instance, a common data store 
provides a data repository that is shared by all four 
component systems. A common Service Management function 
monitors effectiveness and performance of the restaurant's 
RAS system and communicates this information to the RAS 
Central Service Center. A Web Server function provides 
access to the RAS customer functions and the data store for 
all E-Menus and interactive displays in the RAS system. A 
common Configuration function allows restaurant management 
to easily configure various aspects of the RAS 
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implementation to formulate menu content and track 
performance . 

It is the intention of the current invention to not 
5 only provide significant increases in operational 

efficiency, but by its nature, to provide a near-zero ROI 
or time to recover the investment made in the solution. It 
is also the intention of this invention to overcome the 
economic and adoptability barriers faced by current 
10 solutions. 

These objects, as well as other objects which will 
become apparent from the discussion that follows, are 
achieved, in accordance with the present invention, which 
comprises a RAS comprising an AOS including an electronic 
15 menu, and, optionally, a WCS, a RMS and/or a CPS. 

Another embodiment of the invention comprises the 
Waiter Call System, which may be implemented as a stand 
alone Table Call Unit, with or without a decorative 
component. This embodiment may also include a timer 
20 display and/or a call status display. If desired, a server 
may be added to the Water call system, with the Table Call 
Unit in wireless communication with the server, which is 

18 



tracking restaurant management data related to the Waiter 
call System. This embodiment of the invention requires 
little beginning investment, but provides considerable 
value for the diner and the restaurant owner. 

For a full understanding of the present invention, 
reference should now be made to the following detailed 
description of the preferred embodiments of the invention 
as illustrated in the accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 illustrates the overall Restaurant Automation 
System Product Structure, comprising four component 
functions of a preferred embodiment of the present 
invention. 

Figure 2 is a schematic of the overall Restaurant 
Automation System Architecture of a preferred embodiment of 
the present invention. 

Figure 3 is a schematic of an alternative overall 
Restaurant Automation System architecture of a preferred 
embodiment of the present invention, having a different 
software f ramework/E-Menu architecture. Note that the 
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wireless networking technology shown uses 802. 11x and 
TCP/IP standards. This is one implementation option. 

Figure 4 illustrates a second alternative overall 
architecture of the Restaurant Automation System of a 
preferred embodiment of the present invention, having 
another software f ramework/E-Menu architecture. Note that 
the wireless networking technology shown uses 802. 11x and 
TCP/IP standards. This is one implementation option. 

Figure 5 illustrates the home screen of the Menu 
Modify function of a preferred embodiment of the present 
invention accessed through the Kitchen Order Display. 

Figure 6 illustrates the Menu Modify function screen 
for a specific item in the menu according to a preferred 
embodiment of the present invention. 

Figure 7 illustrates the Waiter Call System 
architecture of a preferred embodiment of the present 
invention. 

Figure 8 illustrates the Waiter Call System's Table 
Call Unit used by diners to call the attention of the 
service staff. 
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Figure 9 illustrates the Call Status Display system 
according to preferred embodiment of the present invention 

Figure 10 illustrates the Service Call Process Flow 
associated with the Waiter Call System of a preferred 
embodiment of the present invention. 

Figure 11 illustrates the overall architecture of an 
Automated Ordering System according to a preferred 
embodiment of the present invention. 

Figure 12 illustrates a preferred embodiment of the E 

Menu. 

Figure 13 illustrates a preferred Kitchen Order 
Display Screen of a preferred embodiment of the present 
invention. 

Figure 14 illustrates one embodiment of a Payment 
Station, which consists of a processor with a wireless 
network interface and a touch screen monitor 

Figure 15 illustrates the simplified Bill Payment 
Process Flow for customers making cash payment. 
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Figure 16 illustrates the Table Payment Display screen 
(on the Payment Station Monitor) showing the payment status 
of all tables. 

Figure 17 illustrates the simplified Bill Payment 
Process Flow for customers making credit card payment. 

Figure 18 illustrates the simplified Individual Bill 
Payment Process Flow for individual table diners making 
credit card payments. 

Figure 19 illustrates the simplified Ordering and 
Process flow, with confirmation, for one alternative method 
of a party of three ordering a meal. 

Figure 20 illustrates the simplified Ordering and 
Process Flow, with confirmation, for a second alternative 
method of a party of three ordering a meal. 

Figure 21 illustrates the Reception Management System 
architecture. 

Figure 22 illustrates the Reception Management System 
Table Wait Time Summary screen according to a preferred 
embodiment of the present invention. 
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Figure 23 illustrates the Reception Management System 
Join Queue screen giving customers information on wait 
time, and the ability to enter a queue to wait for a table 
according to a preferred embodiment of the present 
invention. 

Figure 24 illustrates the Reception Process Flow of 
the Reservation Management System for a customer entering a 
full restaurant who decides to wait for a table. 

Figure 25 illustrates the Customer Personalization 
System architecture. 

Figure 26 illustrates the Personalization Function 
Process Flow for a customer participating in the Customer 
Personalization System. 

Figure 27 illustrates a sample home screen on an E- 

menu. 

Figure 28 illustrates the main menu screen from which 
diners can navigate into sub menus, according to a 
preferred embodiment of the present invention. 

Figure 29 illustrates a sample home screen of a 
preferred embodiment of the E-Menu for Internet surfing. 
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Figure 30 illustrates a detailed description screen of 
a preferred E-menu that provides more information on a 
particular menu choice. 

Figure 31 illustrates a sub menu for a particular meal 
course e.g., wine list. 

Figure 32 illustrates the Internet access screen of a 
preferred embodiment of the E-Menu in which diners can type 
in a specific URL to visit a specific web site. 

Figure 33 illustrates the split screen of a preferred 
E-Menu that allows courses to be viewed simultaneously. 

Figure 34 illustrates a photo screen of a menu item, 
provided according to a preferred embodiment of the E-menu 
of the present invention. 

Figure 35 illustrates an E-Menu screen from which a 
display filter may be applied to the menu items presented 
on the E-Menu. 

DESCRIPTION OF THE PREFERRED EMBODIMENTS 
The preferred embodiments of the present invention 
will now be described with reference to Figs. 1-35 of the 
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drawings. Identical elements in the various figures are 
designated with the same reference numerals. 

The Restaurant Automation System (RAS) represents a 
significant evolution in the applied technology and 
improved processing for the service industry, and 
particularly for the restaurant industry. The Restaurant 
Automation System reflects current trends in consumer 
technology and Internet market space and provides benefits 
for both the consumer/diner and the restaurant industry. 

The Restaurant Automation System is an overall system 
that gives the customer greater control over the dining 
experience, while decreasing expenses for the restaurant 
industry. Its most significant component is the E-Menu, a 
remarkable evolution of the traditional hard copy menu. 
The E-Menu essentially allows a restaurant diner to 
transfer orders directly to the kitchen thereby bypassing 
the waiter, and ending the traditional waiter-dependency. 
Herein lies a significant distinction between the 
Restaurant Automation System and other automation systems 
that give only the waiter the means to automatically and 
wirelessly transfer table orders to the kitchen. Whereas 
there are benefits to be realized with this incremental 
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improvement in technology, from the customer's perspective 
the basic problem of waiter dependency is not abated. The 
E-Menu puts total control of the dining experience, from 
menu review to bill payment, in the hands of the customer, 

5 There are other systems that allow the customer to 

directly interface with the kitchen, as described in the 
Background of the Invention, above. Most such systems are 
terminal based and involve a large terminal or Personal 
Computer (PC) like device that must be shared by customers 

10 at a table. Some use a cumbersome and impractical 

alphanumeric interface. None of these systems offer a 
device that is menu-like in its approach , feel, and 
interface. The E-Menu is essentially an electronic version 
of a traditional hard-copy menu as far as customer 

15 interfacing is concerned thereby requiring minimum 

transitional effort and streamlining the adoption process. 

The E-Menu leverages current trends in the consumer- 
oriented Information Technology (IT) market. With the 
increasing use of Personal Digital Assistants (PDAs) , 
20 tablet PCs, and highly functional cellular phones as mobile 
instruments of Internet access, the E-Menu is designed to 
be familiar to the increasingly technology savvy 



population. Yet, the E-Menu's human interface design 
allows it to be adopted easily by the general population. 
The E-Menu not only provides a direct interactive link to a 
restaurant's information database, but also serves as a 
low-cost appliance for Internet access that is available to 
every restaurant customer. 

Today's PDAs are increasingly providing integrated 
network and Internet access capabilities. However, PDAs 
are too small, and too expensive to replace the traditional 
hard copy menu. Restaurant patrons are familiar with large 
menus that traditionally allow viewing at least two pages 
simultaneously, and that allow quick scanning of various 
dining courses at a glance. Today's new tablet PCs provide 
a large viewing area but are fully functional PCs and are 
therefore too expensive and large to deploy to each diner. 
The E-menu represents a low-cost, large display, 
interactive appliance suited for one specific function, and 
hence, produced at a low enough cost to justify its 
deployment to each restaurant patron. 

The E-Menu can be used as an advertising medium to 
provide an additional revenue stream for the restaurant. 
In addition, the E-menu can display Internet web pages. 
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The fact that the Internet can be accessed from such a 
device in a restaurant will, in itself, serve to draw 
additional clients and increase revenue. Such restaurants 
may charge a premium for their food. Alternatively, 
5 incentive programs may be developed to increase revenue. 
For example, if a table's order exceeds $50, Internet 
access is granted to that table. Or, Internet access may 
be provided if a certain special is ordered. 

While the Restaurant Automation System (RAS) is a set 
10 of solutions designed to automate the restaurant industry, 
it is broadly applicable to many service oriented business 
operations. For the restaurant business, this automation 
will result in reduced operational costs and increased 
revenue. For the restaurant customer, use of the 
15 Restaurant Automation System will result in greater control 
over the dining experience and a faster, more efficient and 
more enjoyable dining experience. 

The complete Restaurant Automation System is designed 
with four component systems (WCS, AOS, RMS, CPS), each of 
20 which may be separately tailored to the particular 

restaurant and which can be separately upgraded. The 
Restaurant Automation System permits and encourages the use 



of a common pool of restaurant service personnel in 
contrast to the traditional model in which a particular 
waiter/waitress is designated to serve a group of tables. 
This alters the system to a single queue-multi server 
system such as a bank queue, thereby reducing expected wait 
times ifor service. Additionally, this system ensures 
faster customer seating because the traditional round-robin 
seating rules used to fairly divide the customers among the 
waiters/waitresses is eliminated. 

General Architecture, Figures 1-4 

Figure 1 illustrates the overall RAS product structure 
for a preferred embodiment of the Restaurant Automation 
System^ of the present invention. Figure 1 identifies the 
four component systems of the RAS and their functions. The 
AOS is the core of the RAS. The WCS, RMS and CPS may be 
readily combined with the AOS, for greater efficiencies and 
profit. The components and functioning of the component 
systems will be described below in relation to the system 
architecture. 

Figure 2 depicts the overall architecture of a RAS. 
Note that all components depicted are located within a RAS 

equipped restaurant except for the Internet and the RAS 
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Central Service Center. The RAS coordinates the activities 
in a number of areas of the restaurant. The system depends 
on the RAS Compute Server, 1, which does the work of 
communicating between the various interactive displays and 
E-Menus. The RAS Compute Server runs all the software 
applications and functional processes that provide the 
intelligence of the Restaurant Automation System within the 
restaurant and hosts the restaurant's central data store. 
The infrastructure for communication between the RAS 
Compute Server and the various displays and E-Menus is 
provided by means of a wireless network. This may be 
implemented using a wireless Local Area Network based on 
802. 11x standards, or may be based on wireless cellular 
technology. Within the dining area, 2, customers/diners, 
3, are seated around the table, 4. The table is provided 
with a Table Call Unit, 5. Each of the customers/diners is 
provided with an E-menu, 6. The table may also be provided 
with a separate Table ID signal swipe/generator, 7. Using 
the Table Call Unit, the customers may summon a waiter at 
will, but more particularly, may indicate to the service 
staff, a simple specific request such as a desire for more 
bread or another drink. Using the E-menus, each of the 
customers may explore the menu, requesting details on any 
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particular menu item, place and confirm an order, follow 
the status of an order, etc. 

Within the food preparation or kitchen area, 8, the 
orders placed and confirmed via the E-menus are displayed 
5 for preparation by restaurant staff. This Kitchen Order 
Display will be described in further detail below. The 
Automated Ordering System component of the RAS may also 
include a Payment Station, 9. The customer restaurant 
bills are presented for payment (by display, and with an 
10 optional printout) at the Payment Station. The bills are 
tabulated at the request of the customer. The Payment 
Station will be described in greater detail below. 

The overall RMS component of the Restaurant Automation 
System includes a Reception Display, 10, in the reception 

15 area, 11 and a Reservation Display 10.1. At the Reception 
Display, customers without a reservation are permitted to 
enter a reservation, and perhaps to view a screen 
containing estimates of table wait time. At the 
Reservation Display, restaurant service staff may enter 

20 reservations that customers have phoned in. The Reception 
and Reservation Displays will be described in further 
detail below. 
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The RAS Central Service Center 31 hosts the RAS 
Central Service Center personnel 32 who monitor the health, 
or functioning and effectiveness, of various RAS equipped 
restaurants by analyzing data that is fed from each 
restaurant's RAS Compute Server. The RAS Central Server 33 
maintains this consolidated information. The RAS Central 
Server also maintains consolidated information on frequent 
diners of RAS equipped restaurants in support of the 
Customer Personalization System. 

Figure 3 illustrates one basic software alternative 
for the Restaurant Automation System architecture, 
illustrating its components and connections to other 
displays in the Restaurant Automation System. New 
applications can be easily added onto the Restaurant 
Automation System compute server as new technologies are 
developed and/or new needs arise. It is the RAS compute 
server which accumulates the information regarding occupied 
tables and calculates expected table wait time for the 
Reception Display, based on orders placed, served, and 
phone-in reservations. It is the RAS Compute Server that 
communicates the orders to the Kitchen Order Display, 8, 
and the total costs of the order to the Payment Station, 9. 

Preferably the RAS compute server is connected to a 
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broadband Internet service, which can provide Internet 
browsing on the E-menus via a Proxy Server function. All 
software and hardware functions in the E-Menu must be 
lightweight i.e., they must minimize use of memory space, 
processing cycles, power, etc. One of the main success 
criteria of the E-Menu is that it be inexpensive enough to 
distribute to every diner. Only by efficiently designing 
software, minimizing licensing costs, and minimizing 
hardware costs, will a feasible cost target be attainable 
for the E-Menu. 

Note that the Figure depicts a TCP/IP and 802. 11x 
based network. This may be implemented using a wireless 
Local Area Network based on 802. 11x standards, or may be 
based on wireless cellular technology. The RAS is based on 
wireless networking which may be implemented using any of a 
number of technologies. 

Figure 4 illustrates an alternative architecture for 
the RAS that minimizes the hardware and software 
requirements on the E-Menu thereby minimizing its 
development and production cost. In this approach, the E- 
Menu simply serves as an interactive display device without 
a Central Processing Unit (CPU) . 
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Note that there are 2 implementation architectures 
that are proposed as depicted in Figures 3 and 4. Figure 3 
depicts an architecture in which the E-Menu has a Central 
Processing Unit (CPU) . In this alternative, the RAS 
Compute Server transmits html pages and other data forms 
from its data store that represent the information 
requested from the E-Menu. This information is transmitted 
over the wireless network infrastructure to the requesting 
E-Menu device. The E-Menu 's CPU interprets these html 
pages (and other data forms) and converts them to a 
presentable graphical format that is then displayed on the 
E-Menu' s LCD display by the graphics adapter. 

Figure 4 depicts an architecture in which the E-Menu 
does not have a CPU. In this case, the process of 
interpreting html pages (and other data forms) and 
converting them to a presentable graphical format is 
performed by the RAS Compute Server. The RAS Compute 
Server then transmits this pre-processed graphical data 
over the wireless network infrastructure to the E-Menu. 
The graphics adapter in the E-Menu then presents this 
graphical data to the E-Menu 's LCD display. 
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The advantage of the architecture depicted in Figure 3 
lies in the fact that html pages (and other data forms) 
represent a relatively small amount of data that must be 
transmitted over the wireless network. Additionally, this 
5 is a standard methodology used in web communications today. 
However, the disadvantage is that a CPU is required on the 
E-Menu to interpret these data forms and convert them to 
graphical information thereby increasing its cost. The 
advantage of the architecture depicted in Figure 4 lies in 
) the fact that since the data-form-to-graphics 

interpretation work is already done by the RAS Compute 
Server, a highly functional CPU is not necessary on the E- 
Menu. The E-Menu becomes a simple terminal display device. 
However, with this E-menu configuration a great deal of 
graphical data must be transmitted over the wireless 
network infrastructure and this may result in which may 
affect performance. Also, the RAS Compute Server must bear 
the load of managing multiple E-Menu sessions and display 
directions. Hence, a more powerful RAS Compute Server 
platform would be required. 

Note that the Figure depicts a TCP/IP and 802. 11x 
based network. This may be implemented using a wireless 

Local Area Network based on 802.11* standards, or may be 
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based on wireless cellular technology. The RAS is based on 
wireless networking which may be implemented using any of a 
number of technologies. 

AS Common Functions 

There are a number of underlying functions and 
resources provided by the RAS that are common to the four 
main component systems. These common functions include the 
data store, web server, Service Management function, and 
Configuration Function. 

The data store may be a commercially available 
database, embedded database, open source code, or may be 
specifically developed for the RAS. The data store 
provides a common data repository of information that 
supports all the four main customer oriented functions 
(WCS, AOS, RMS, CPS). The data maintained in the data 
store on a restaurant's RAS compute server includes, but is 
not limited to, the following: 

• Menu items, descriptions, photos, prices, etc. 

• Hyper-links to sites advertising on E-Menus 

• Data on closed service calls (time to call 

completion, table ID, etc) 
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• Reservation scheduling data 

• Marketing information such as dishes ordered, web 
sites visited, length of meal, number of persons per 
party, etc. 

• Error and performance information related to the 
restaurant's RAS system (transmitted regularly to 
data store on RAS Central Server) . 

A data store resident on the RAS Central Service 
Center server includes, but is not limited to, the 
following data: 

• Dining pattern information collected from various 
RAS equipped restaurants on frequent diners such as 
types of meals, dining frequency, dining geography, 
RAS customer ID, etc. 

• Error and performance information across all RAS 
equipped restaurants 

A web server running on each restaurant's RAS Compute 
server can provide standard access to the information in 
the underlying data store to the web browser function 
running on E-Menus. The web browser provides the common 
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data access mechanism for E-Menus and for the various 
interactive displays involved in the RAS . The software for 
this application may be commercially available software, 
open source code, or specifically designed for the E-Menu. 

A common Service Management function running on the 
restaurant's RAS compute server monitors the health, or 
functioning and effectiveness, as well as the performance 
status of various components of the RAS compute server and 
sends this data to the RAS Central Service Center Server's 
Service Management function. Here, the RAS Central 
Services Center personnel can analyze the data and take 
proactive remedial actions. The following lists some of 
the items that may be monitored by the Service Management 
function: 



• Restaurant's network utilization and performance 
rates, error rates, etc. 

• RAS compute server disk, CPU, memory utilization 

• Broadband link utilization 

If the RAS Central Services Center personnel detect 
that something may impact service at a RAS eguipped 
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restaurant, they may contact the restaurant's management or 
may dispatch a service technician to resolve the issue. 

A common Configuration Function allows restaurant 
management to configure various aspects of the RAS system. 
For example, for the AOS, the configuration function allows 
the restaurateur to update the menu items, descriptions, 
prices, photos, etc. quickly and easily. This is in 
contrast to traditional hard copy menus that must be 
reprinted when menu items or prices change. Daily specials 
may be changed daily electronically rather than by updating 
a chalkboard. For the RMS, the restaurateur may configure 
how long the restaurant should wait for a party that has a 
reservation before making their table available to other 
diners. The configuration function provides a simple 
Graphical User Interface (GUI) that allows data entry by 
any member of the common service staff pool. 

As the Configuration function runs on the RAS Compute 
server, it can be accessed from any restaurant display 
including the Payment Station display or the Kitchen Order 
Display. The function should be password protected. 
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One frequently used function, the Menu Modify 
function, of the Configuration function is a process that 
allows, the restaurant management to add/change/delete 
items, daily specials, descriptions, photos, pricing, etc. 
on the menu. 

Figure 5 depicts the main, or home, screen of the Menu 
Modify function. This screen allows restaurant management 
to select which part of the menu they want to update or if 
they want to create a new category or section in the menu. 

Figure 6 depicts the Modify Screen that allows the 
actual update of information for a specific item in the 
menu. After changes are made, such as by simply typing in 
new information, restaurant management can save changes. 
The changes take effect immediately in the data store and 
the new information is available to diners via the E-Menu. 

Waiter Call System 

° One of the four components of the Restaurant 
Automation System is the Waiter Call System (WCS) . The WCS 
provides a system by which a restaurant customer can 
efficiently call the attention of any member of the 
restaurant's service pool. The actual call process may 
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also provide an indication of what the customer desires 
thereby eliminating the inefficiency of the "double-trip". 
The WCS may be designed with an optional Call Status 
Display function that centralizes the display of all 
5 customer service requests. 

Figure 7 depicts the WCS Architecture. Its components 
are described below. 

10 Table Call Unit 

The basic unit of the Waiter Call System is the Table 
Call Unit (TCU) . Figure 8 depicts the Waiter Call System 
Table Call Unit according to a preferred embodiment of the 
present invention. The TCU has several buttons, 12, 
15 associated with the most frequently requested service 
functions. These can be interpreted to mean anything a 
particular restaurant determines suitable. For each 
button, a distinct color light or pattern is displayed in 
either a standard display, e.g. service call lights, 13, or 
20 an attachable decor- integrated light display such as at 14, 
suitable for the restaurant. For the service staff 
scanning the dining floor, this gives an immediate 
indication not only of the fact that a particular table 
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requires service, but additionally, based on the 
color/pattern of the display, exactly what service is being 
requested. This eliminates the wasteful "double-trip" in 
which the waiter/waitress makes one trip to determine what 
the diner wants and then another trip to satisfy the 
request . 

Table 1 below provides an example implementation. 



Button 



Color displayed 



Function 



1 


Orange 


Service Personnel 
requested for 
inquiry, etc. 


2 


Blue 


Water requested 


3 


White 


Cash payment 


4 


Repeating blue pattern 


Soda refill 



The WCS table unit may contain an integrated timer 

with display, 15. When a service button is pressed, a 

timer is started that displays in seconds, the amount of 

time elapsed until the service call is fulfilled and the 

timer is manually stopped with the "end call" button. T] 

function serves as a quality of service gauge. 
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The Table Call Unit may also contain a Table ID 
transmitter/RFID swipe device 7 that transmits a unique 
table ID that is received by the Automated Ordering 
System's E-Menu units (described in next section). In 
order to prevent one table's E-Menus from receiving the 
table ID transmissions from another table's transmitter, 
the transmitters may be set to a low power thereby 
requiring close proximity of the E-Menu in order to 
establish the table ID onto the E-Menu. This function of 
setting a unique table ID on a table's E-Menus can 
alternatively be implemented by use of a Radio Frequency 
Identification (RFID) based means. This would allow an E- 
Menu to be swiped across an RFID unit that electro- 
magnetically affixes a unique table ID onto the E-Menu. If 
the E-Menu is moved to another table, it is swiped at that 
table's RFID transceiver and all subsequent operations from 
that E-Menu are associated with the new table. If a 
restaurant implements both the Waiter Call System and the 
Automated Ordering System, this transmitter or RFID 
transceiver is embedded in the Table Call Unit. If only 
the Automated Ordering System is implemented without the 
Waiter Call System, then the table ID transmitter/RFID 
transceiver means is affixed to or embedded within the 
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dining table. The Table ID transmitter/RFID swipe device 
is modular so that it may be plugged into or removed from 
the TCU or the table easily. 

As will be discussed in the next section, a modular 
wireless means is also used in the TCU for restaurants that 
have the optional Call Status Display. This wireless means 
allows transmission of call request data to the RAS Compute 
Server (or alternatively, directly to the Call Status 
Display if the AOS/RAS compute server are not subscribed) 
which then relays it to the Call Status Display(s) . This 
wireless means is modular so that it may be easily plugged 
into or removed form the TCU. 

Call Status Display Option 

The Waiter Call System with the lighted Table Call 

Unit display is well suited for open spaced dining areas 

that can be scanned easily for the Table Call Unit lights 

or where there are a large number of service personnel. In 

restaurants that have partitioned seating areas or where 

the dining floor contains secluded sections, it may be 

difficult for service personnel to scan all areas easily 

and respond quickly. In such environments, it may be 

appropriate to supplement or substitute the lighted Table 
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Call Unit displays with one or more Call Status Displays, 
such as at 16 in Figure 9 that would be located at a 
position(s) in the restaurant easily viewable by the 
service personnel. This is a RAS Compute Server-based 
function that can be monitored via the Call Status 
Display (s) throughout the restaurant. In this preferred 
embodiment the function and display provide an easily 
viewed Graphical User Interface (GUI), 17, that displays 
the service call status of all tables. Colors reflect the 
amount of time that has elapsed since the customer request 
and hence, the urgency of responding. Touching the screen 
at a particular location, such as at "end call" may produce 
a particular result such as deleting the service request 
line from the display and entering data about the request 
such as type, table ID, time to completing request, etc. 
into the RAS Compute Server's data store. Pressing the 
end-call button 17.1 on the TCU has the same effect. 
Reports can then be generated from this stored data that 
can be used by the restaurateur to help identify service 
issues . 

If the Call Status Display is used, it is necessary to 
introduce a wireless communications means within the Table 

Call Unit. This wireless communications link is used to 
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communicate data related to the service request to the RAS 
Compute Server over the wireless network infrastructure. 
The RAS Compute Server then transmits this information to 
the Call Status Display(s) . 

5 It is also possible to implement the WCS with the TCU 

and a Call Status Display but without the RAS compute 
server. In such an implementation, pressing a service 
button on the TCU generates a wireless transmission to the 
Call Status Display directly where all service calls can be 

10 monitored. In this case, the Call Status Display has a 
wireless receiver, LCD touch display, memory, and 
intelligence to display the service calls and delete them 
when the "end call" button is pressed. Since there is no 
RAS compute server involved, the benefits of service call 

15 data collection and reporting are not available. 



WCS Function 

The WCS function resides on the restaurant's RAS 

compute server. When a table makes a service request via 

20 the Table Call Unit, the TCUs wireless interface sends the 

request to the WCS function. The WCS function forwards the 

request information (table ID, type of request, etc.) to 

the Call Status Display. When the service call is 
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fulfilled and the "end call" button is pressed either on 
the Call Status display or on the TCU, a message is 
conveyed to the WCS function to remove the service call 
information from the Call Status Display and saves the 
request information in the data store for future service 
reporting/analysis . 

As previously mentioned, the WCS function runs on the 
RAS compute server and hence, is applicable when the WCS 
system is implemented with the RAS compute server. It is 
possible to have the TCU directly transmit to the Call 
Status Display without the WCS function. In this case, the 
benefits of tracking service call data and reporting would 
not be available. 

WCS Process Flow 

Figure 10 depicts the process flow associated with the 
Waiter Call System. As shown, when the customer requires 
service they may use the service call buttons, 12, of the 
Table Call Unit to indicate a request for water, cash 
payment, or some other designated service. The Table Call 
Unit and/or the Central Call Status Display (s) alert the 
service staff to complete the request. Thereafter, the 

"end call" button may be pressed on the Table Call Unit 
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and/or the Call Status Display. Data related to the call 
is then stored in the RAS compute server's data store for 
future analysis/reporting (if implemented in conjunction 
with the RAS compute server) . 

Automated Ordering System 

The most preferred Automated Ordering System (AOS) of 
the present invention consists of five main components: the 
E-Menu, the Table ID transmitter/RFID swipe device, Kitchen 
Order Display, the Payment Station, and the Automated 
Ordering System function, 18, residing on the RAS Compute 
Server. Figure 11 depicts the Automated Ordering System 
architecture. 

In the Automated Ordering System, the traditional hard 
copy menu is replaced with a hand held electronic device 
with a large touch sensitive LCD display. This device, 
called an E-Menu, is a low cost electronic appliance that 
provides diners access to a database of rich content 
information residing on the RAS Compute Server. This 
information includes the menu, photos of menu selections, 
information on the restaurant, chef background, nutritional 
information, call status information, access to web 
servers, etc. 
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The Automated Ordering System function provides 
various functions to the diners by coordinating and 
processing input placed by diners via the E-Menu and 
various interactive displays throughout the restaurant. 
For example, the AOS generates orders for the kitchen and 
displays the orders on the Kitchen Order Display, processe 
billing, interacts with the Payment Station to settle 
bills, etc. The Automated Ordering System function may 
also maintain food preparation status information that can 
be easily viewed by the diners on the E-Menu. This may 
facilitate a desired order change. Wireless networking 
technology is used as the communications infrastructure 
between the various components of the Automated Ordering 
System. 



E-Menu 

The E-Menu is one of the core components of the 
Automated Ordering System. The E-Menu is a low-cost, large 
touch sensitive display, appliance with built-in wireless 
networking and rechargeable power source. The E-Menu 
serves as the diner's primary interface to the Automated 
Ordering System. 
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Figure 12 depicts a possible implementation of the E- 
Menu, 6, with the large interactive touch screen display, 
20, and embedded wireless networking interface, 21. 
Preferably the E-menu /also has brightness/contrast 
controls, 22, readily accessible by the customer/diner, and 
an optional pointing device, 23, which may be used on the 
touch screen, 20. The charging system for the E-menu has a 
low battery indicator, 24 and battery charging contacts, 
25. 



The E-Menu consists of the following essential 
hardware (specifics are subject to change depending c 
method of implementation) : 

• Large touch screen display (b/w or color) 

• Video display adapter 

• Memory (either RAM or video memory onboard video 
adapter depending on implementation) 

• Rechargeable power source 

• Low battery indicator 

• Battery charging interface/contacts 

• Integrated wireless communication interface 

• Brightness/contrast controls 

50 



10 



• Pointing device 

• An interface that allows for firmware upgrades (not 
shown in picture - this may be performed via wireless 
network interface) 

• May contain a Central Processing Unit (CPU) depending 
on implementation 

• Reset button 

• RFID receiver or electromagnetic means of receiving 
table ID 

There are two primary methods of implementation 
envisioned for the E-Menu as described in the discussion on 
the software architecture alternatives in relation to 
Figures 1-4. First, the E-Menu may contain a CPU. In this 
case, the E-Menu may run a light operating system that 
minimally serves the purpose of the E-Menu device. This 
may be a commercially available operating systems such as 
Microsoft's Pocket PC ®, 3Com's Palm OS ® , a commercially 
available embedded operating system, open source code, or 
may be specifically developed for the E-Menu. The E-Menu 
may run a web browser function which is also a light 
function that communicates with the Automated Ordering 

O 

System server function via the RAS compute server's web 
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server over a wireless network and a standard protocol such 
as HTTP and graphically presents html page information from 
the Automated Ordering System function to the diner. 

5 The E-Menu may alternatively be implemented as a light 

"display client" that has no CPU or noteworthy operating 
system. In this case, the E-Menu's main components would 
consist of a wireless network interface, touch sensitive 
LCD display, and a video adapter. In this implementation, 
10 the RAS Compute Server would assume the responsibility of 
interpreting html and other data forms into a graphical 
file that would be sent over the wireless network to the E- 
Menu that would then simply display the graphics file to 
the diner. For a discussion of the advantages and 
15 disadvantages of each implementation approach, see the 
discussion on software architecture alternatives in 
relation to Figures 1-4. 



20 



The main intelligence of the Automated Ordering System 
resides in the Automated Ordering System function running 
on the RAS Compute Server. The E-Menu simply provides a 
platform by which customers access the Automated Ordering 
System function and the data in its underlying database. 
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The Automated Ordering System function allows diners to 
categorically (e.g., by vegetarian, chicken only, seafood 
only, price range, etc.) filter the display of menu items. 
The E-Menu presents and displays this information to the 
customer and allows the customer to navigate through the 
Automated Ordering System functions. The Filter Display 
function accessed from the E-Menu is displayed in Figure 
35. 



The E-Menu provides flexible viewing options that for 
example, allow two meal courses, or sub-menus, to be viewed 
at once by dividing the screen into two sections. This 
allows easy comparison of, for example, appetizer items and 
main course items. Figure 33 depicts this function. With 
this function, the diner may bring up a window for each 
course, and scroll through the offerings, while viewing the 
selections for another course in another window. While the 
definition of courses may differ from restaurant to 
restaurant, and menu to menu, what is intended by this 
function is to achieve a scrollable window for each sub- 
menu or section of the menu. In fact, each hyperlink in 
the E-menu can bring up a new window. 
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I t 

I 1 

The price of the E-Menu must be kept minimal and its 
performance must be maximized for its cost. To this end, 
it is preferred that all extraneous functionality and 
processing is eliminated from the E-Menu thereby making it 
5 an appliance type of device. 

Each E-Menu contains a means of receiving a Table ID 
from a Table ID transmitter/RFID swipe device that is 
either embedded in the Waiter Call System's Table Call Unit 

10 as previously described or embedded/affixed to the table as 
an independent device. This Table ID is then sent along 
with the individual's order in the transmission to the AOS 
function where it is collated with other orders from the 
table. If an E-Menu is handed to someone else at another 

15 table, it can pick up the new table's ID signal via 

proximity to the signal source or via swiping across an 

RFID transceiver. 

■\ 

The E-Menu demonstrates physical tolerances 
20 appropriate for the environment in which it is used. It 
shall withstand hot and cold liquid spills, vibrations, 
drops, food spills, etc. The E-Menu provides a display 
brightness and contrast adjustment control to facilitate 
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viewing in dark restaurants or in well lit or street side 
facilities. The E-Menu interface and selection buttons are 
sized appropriately for use by human fingers. However, a 
touch screen pointing device, 23, is also provided as an 
5 attachment on the E-Menu for those who prefer this option. 

One of the primary concerns of the E-Menu is that is 
look and feel like a traditional hard-copy menu. The E- 
Menu provides a simple, flowing interactive process that 
) facilitates its use and adoption. The size, user 

interface, and other human interface characteristics are 
designed to serve this end. 



In fact, the new foldable LCD screen would assist in 
creating an E-menu that, at first glace looks like a hard 
copy menu, but contains many layers of information. 
Foldable color LCD displays have been introduced by a 
number of manufacturers. Most use plastic polymer 
semiconductors instead of silicon. Toshiba and NEC/Samsung 
have introduced foldable PC monitors. The NEC/Samsung 
model has an acrylic screen and a flexible frame. 
Surprisingly, the cost of the foldable LCD monitors is 
about the same as for the older flat LCD screens. Samsung 
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was the first to introduce foldable LCD screens. Their 
8.4-inch monochrome display which was showcased at the 
Korea e-book industry tradeshow in April 2002. Unlike NEC- 
Mitsubishi's collapsible offerings that are targeted at 

5 desktop users, Samsung's Black and White monitor is meant 
as a display for electronic books. In light of its niche 
application, the 8.4-inch screen uses Cholesteric LCD 
technology, a feature that allows the monitor to retain 
images even without a power supply. Though this might be 

) sufficient for certain restaurant menus, many restaurants 
will want full color menus. 



For those customers that prefer a traditional dining 
process, the E-Menu can be used as a traditional menu for 
the purpose of viewing items, descriptions, etc. For order 
placement, the customer may request that a member of the 
service staff place the order via an E-Menu on his behalf. 
The bill payment process can also be handed to the service 
staff for administration. Thus, the AOS accommodates 
diners who want to leverage the benefits of the automations 
system and gracefully accommodates diners who prefer a more 
traditional dining process. 



56 



At the same time, the E-Menu provides functions that 
cannot be provided by a traditional hard-copy menu. For 
example, the E-Menu allows diners to view photos of the 
menu items, allows for flexible billing options, provides 
5 background information on the chef, serves as an 

advertising platform, etc. These functions are integrated 
into the E-Menu user interface in a manner that is non- 
intrusive to its core function of placing food orders and 
yet, are easily accessible when desired. Each diner is 
3 thus simultaneously provided with a wealth of information, 
and the ability to place an order. This point is in 
contrast to other proposals that require multiple diners at 
a table to sequentially interact with a table based 
ordering system that is not menu-like in its approach but 
rather, bulky and computer- like. Additionally, these 
systems require the individual diners at the table to wait 
for their turn to view the menu information and place 
orders . 



Table ID Transmitter/RFID Swipe Device 

The Table ID transmitter/RFID swipe device interacts 
with the E-Menu by assigning a table ID to the E-Menu. 
This may be achieved via electronic, electromagnetic, radio 
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frequency, or other means. If the restaurant is equipped 
with the Waiter Call System, then the Table ID 
transmitter/RFID swipe device may be embedded within the 
Table Call Unit. If the restaurant has not subscribed to 
the Waiter Call System, the Table ID transmitter/RFID swipe 
device may be embedded/affixed to the table itself. 

The physical distance required between the E-Menu and 
the Table ID transmitter/RFID swipe device in order to 
effect setting of the table ID on the E-Menu must be 
relatively small. This ensures that the table ID will not 
be picked up by E-Menus at other tables. 

Whether a proximity based transmission is used or a 
swipe device will depend to some extent on the table layout 
of the restaurant. Table proximity and positioning will be 
factors in this decision. 

The Table ID transmitter/RFID swipe device is 
preferably a modular unit that can be plugged into or 
removed from the TCU. It may also be plugged into or 
removed from a table base unit that is affixed to or 
embedded within a table. This allows easy transition for 
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restaurants that have subscribed to the AOS and want to add 
the WCS, or for restaurants that want to change their 
tables . 

5 Kitchen Order Display 

The Kitchen Order Display receives confirmed orders 
from the AOS function. The AOS function transmits 
confirmed orders along with the associated table ID to the 
Kitchen Order Display for the kitchen staff to view. Based 
10 on the floor plan and/or size of the kitchen, there may be 
more than one Kitchen Order Display. Figure 13 illustrates 
an order screen such as would be displayed on the Kitchen 
Order Display, 26. 

15 Because many orders may arrive in a short time during 

busy periods, the Kitchen Order Display may be implemented 
using a display that is longer in height than in width 
thereby allowing a greater number of orders to be 
simultaneously displayed. A printer may be attached to the 

20 Kitchen Order Display via a cable or wireless means. 

The AOS function manages how orders are displayed. 
For example, when individual orders start arriving from a 
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table for a particular meal course in a short time window, 
the AOS function attempts to collate them on the Kitchen 
Order Display. If a late order arrives from the same 
table, the AOS will attempt to place the order at the end 
of that table's order on the display and will flash the 
order in a distinct color. The AOS function may remove 
from the display the oldest orders, for which preparation 
has started. 

When the chef starts preparation for an individual 
order, he may press the "Prep Started" button to indicate 
to the AOS function that it is now too late for the 
customer to change/cancel the order. This information will 

be displayed to the customer on his E-Menu by accessing the 
"Order Status" function on the E-Menu. Until the chef 

presses the "Prep Started" button, the customer may access 

his order from the E-Menu and change/cancel the order. 

This change will be reflected by the AOS function on the 

Kitchen Order Display. 

The chef may also choose to print a particular order 
by pressing the "Print Table Order" button. 
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Payment Station 

The Automated Ordering System function also provides a 
billing function that takes a table's order information, 
generates a bill, and sends the information to a Payment 
5 Station where diners can make payment. 

The Payment Station may be provided with a touch 
screen interface through which diners can identify their 
table, print a bill, and make credit-card payment. The 
10 Payment Station may consist of a processor with a wireless 
network interface and a touch screen monitor as depicted in 
Figure 14. Alternatively, the Payment Station may be a 
light "display client" with a video adapter, large touch 
sensitive screen, and wireless network interface. The 
Payment Station may also provide a credit card swipe device 
with a built-in printer and electronic signature capture 
means so the restaurant does not need to physically track 
signed receipts. 



Cash payment can be made to a member of the service 
staff. A cash payment request button may be one of the 
buttons on the Table Call Unit of the Waiter Call System. 
(The traditional method of calling a waiter's attention 
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must be used if the WCS has not been subscribed) . In 
addition, a member of the restaurant common service pool 
may access a password protected "cash payment" function 
accessible on the Payment Station display. After 
5 depositing the cash and removing change, the service 

personnel may then indicate that the table's bill has been 
settled via the Payment Station's touch screen. 
Alternatively, a specific cash Payment Station may be used 
that is located in an area not accessible by customers. 
0 Once payment is made, this information is fed back to the 
AOS function that then updates the table status in other 
functions such as the Reception Management System discussed 
later. Figure 15 depicts the process flow associated with 
cash payment. 

A Table Payment Status screen can be accessed via a 
password protected function on the Payment Station display 
(or a dedicated Payment Station only accessible to 
restaurant staff) . The Table Payment Status screen, 
accessible at the Payment Station 9 displays the following 
payment states associated with tables: 

i 

• Payment pending 
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• Partial payment made (in cases of multiple bills per 
table 

• Payment made and subsequent order 

• Payment settled 

Display colors may be associated with each state to 
provide a quick assessment of the payment state of occupied 
tables. For example, Payment Pending may be indicated in 
red while Payment Settled may be indicated in green. 

The Table Payment Status screen is depicted in Figure 16 

Bill Payment can also be made in the traditional 
manner by a member of the restaurant's common service pool 
at the request of the customer if so desired. In this 
case, the customer can call the service pool via the Table 
Call Unit (if equipped) and then give his credit card or 
cash for the service personnel to administer the payment 
process . 

The number of Payment Stations at a restaurant will 
depend on the establishment's floor space, situational 
scenario, cost, etc. At minimum, a single Payment Station 
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is required. However, each table could have its 
Payment Station. 



AOS Function 

The AOS function coordinates the interaction between 
E-Menus, the Kitchen Order Display(s) , and Payment 
Station(s) . 



The Automated Ordering System function sits atop a 
data store, 27 in Figures 3 and 4, and accesses data that 
is related to its function. The AOS function maintains 
active data related to all aspects of a table's dining 
status from the point a party arrives at a table to the 
point that all bills have been settled and the party 
leaves. The AOS function also accesses and presents less 
dynamic information in the data store such as menu items, 
photos, chef background, etc. 



The Automated Ordering System application provides 
functions available to the diner that are accessed via the 
E-Menu. Diners can place orders via the E-Menu. The 
Automated Ordering System application maintains a record of 
items ordered by individuals and by the table as a whole 
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and also maintains billing information according to the 
desired billing policy for the table. The Automated 
Ordering System application also makes status information 
on food preparation input by the cooking staff available to 
5 diners. Diners can also update, cancel, or change orders 
after they are placed providing a real-time degree of 
ordering flexibility. 

The AOS also allows data from the data store to be 
) requested and presented in certain ways. For example, a 
Filter Display function accessible from the E-Menu allows 
the menu data to be filtered based on specific criteria 
such as vegetarian, kosher, chicken only, by price range, 
etc. This function is depicted in Figure 35. 

An automated billing process is incorporated into the 
Automated Ordering System. Automated billing allows a 
party to pay its bill(s) at any time during the meal. 
Customers do not need to wait for the check or for anyone 
to swipe credit cards and return, etc. This allows 
customers to leave immediately after completing their meal 
if they wish. 
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When a diner decides to pay the bill, he/she makes an 
indication on the E-Menu (or walks to an Payment station 
and enters his/her table number on the user interface) . 
This request is sent to the Automated Ordering System 
function that totals the table's bill according to the 
billing policy for the table and sends this information to 
the Payment Stations. Figure 17 depicts the Process Flow 
associated with a diner making a credit card payment for 
the table. 

Various billing policies may be implemented in which a 
single or a number of separate bills per table may be 
requested. The default operation assumes that there will 
be a single bill associated with the table order. No 
action needs to be performed by any diner to establish this 
billing policy that reflects the vast majority of billing 
situations. In the exceptional case that individuals at a 
table want a separate bill for their own orders (as for 
some business meals in which individual receipts are 
required for expense purposes), each diner may interact 
with an option available on the AOS function via the E-Menu 
that, at order confirmation, allows the diner to associate 
the order with a distinct bill. The Automated Ordering 
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System function keeps track of the various individual 
orders from the table and associates an identifier with 
each individual order along with the table that it comes 
from forming a table/individual order ID (e.g., 4b 
5 represents an order from individual b, at table 4). when 
the AOS Application sends a confirmation of the individual 
order back to the E-Menu, the table/individual identifier 
is also sent. When an individual diner picks up an E-Menu 
and appends to his/her order (e.g. dessert/coffee), the 
10 Automated Ordering System Application may ask the diner for 
the table/individual ID to which to append to. In case the 
individual has forgotten the ID, he/she may request that 
the AOS Application display all orders from the table from 
which he/she may then select his/her order to append to. 
Hence, the entire process works as it does for simple 
collective table billing, but may have one greater degree 
of resolution (introduction of the individual identifier). 

Figure 18 depicts the process flow for tables 

i 

involving individual billing. For tables at which at least 
one diner has requested an individual bill, payment is 
handled by using the table/individual ID. The individual 
may pick up an E-Menu and send a request to the AOS 
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Application that his/her bill be tallied based on the 
table/individual ID (or he/she may walk up to a Payment 
Station and make the same request) . The diner may then go 
to the Payment Station, review his/her bill, and make 
payment. At the Payment Station, the diners can pay their 
bills via credit card and can print a receipt. 

It should be noted that the restaurant staff may 
provide adjustments to a bill. For instance, a printout of 
a complementary order of after-dinner drinks may appear on 
the bill. In another example, a discount may be applied to 
a bill, to illustrate to the diner the benefits of a 
particular dining program. In order to apply the 
adjustment, a member of the restaurant staff, using an 
enabling pass-code for bill adjustments, may apply the 
adjustment to the bill using another E-menu, or the 
Reservation Display, or other access to the server, or 
directly to the payment station. 

The restaurant staff is made aware that payment has 
been made for a table. This notification is reflected on 
the Table Payment Status screen on a Payment Station 
display, which can display the payment status of all 
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tables. Access to this screen may be password protected o 
it may be physically accessible only by restaurant staff. 
Colors could be used to reflect the payment status of each 
table. The Table Payment Status screen is depicted in 
5 Figure 16. 



The Automated Ordering System allows diners to place 
orders after payment has been made and alerts the 
restaurant staff that billing will be made for additional 

10 items. This accommodates diners that change their minds 
after payment and decide to have, for example, dessert or 
coffee. Diners will need to make another payment for these 
additional items. Placing an order after payment for the 
table (or individual) payment has been made changes the 

15 payment status of the table to, i.e. "Payment with 
Subsequent Order". 

AOS Process Flow 

Figure 19 depicts a simplified process flow for a 
Z0 party of three ordering a meal in a professional oriented 
restaurant where it is assumed that diners can order 
quickly and easily. There are a number of ways to address 
the concept of confirming the table order. First, there 
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may be no confirmation (as in Figure 19). As each diner at 
a table sends his/her individual confirmed order, it is 
received by the AOS Application on the RAS Compute Server 
and subsequently displayed on the Kitchen Order Display. 
As each individual order is received, it is correlated with 
other orders from that table and displayed collectively on 
the Kitchen Order Display. This method works well in 
environments that cater to professional diners who can 
responsibly place and confirm their individual orders 
within a focused time frame so that all individual orders 
are displayed in the kitchen at approximately the same 
time. 

In a preferred embodiment, the E-menus may be provided 
with a means to disable the "sent order 11 function. This 
would be advantageous in the instance when a parent wants 
to order for a child and thereby prevent any erroneous 
orders from the child menu. This could be accomplished by 
a disable button on the E-menu, which could be pressed by 
the waiter, seater, or parent. Alternative means could 
comprise a password protected disable function. There are 
many ways of accomplishing this disabling of the order send 
function, which will be known to those skilled in the art 
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Figure 20 depicts an alternative approach that 
involves designating a single E-Menu at a table as the 
"confirmer" E-Menu. This may be the first E-Menu swiped at 
5 the Table ID signal transmit ter/RFID swipe device. A 
unique E-Menu ID is then transmitted to the AOS function 
identifying it as the "confirmer" E-Menu for the table. 
This E-Menu can then be handed to the table's "head" diner 
(the one responsible for payment, or based on some other 
10 criteria) . After all individuals place their confirmed 

orders with the RAS Compute Server's AOS function (with the 
"head" diner's order being the final one and indicating 
that all individual orders have been placed) , the AOS 
function sends the entire table order to the table's 
15 "confirmer" E-Menu for final confirmation of the table 
order. This method is suitable for family oriented 
restaurants where a parent's final 

authorization/confirmation is required before an order is 
accepted and sent to the Kitchen Order Display. If changes 
20 need to be made by the "head" diner (e.g., deletion of 

multiple ice cream orders), he may do so and then send the 
final approved table order. 
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An alternative for the family restaurant involves 
providing a means of disabling the "send order" function 
temporarily on certain menus - perhaps the ones given to 
children. Hence, the children are granted all E-Menu 
5 functionality but cannot send confirmed orders. It is the 
parent's responsibility to collect and send confirmed table 
orders. Finally, a simple approach to family restaurants 
involves not providing E-Menus to children at all. 

10 Reception Management System 

The Reception Management System (RMS) functionally 
sits atop the Automated Ordering System. The RMS function 
uses input from the Reservation and Reception displays and 
leverages data from the AOS function to generate estimates 
15 of table wait times and presents these wait times to 

arriving customers. Arriving customers can then decide if 
they want to wait for a table or leave. If they decide to 
wait for a table, the RMS function allows them to enter 
their names into electronically displayed queues via the 
20 Reception Display. The RMS function also interacts with a 
Reservation Display that accepts phone-in reservations and 
coordinates these reservations with table requests made via 
the Reception Display. 
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The RMS function uses table request inputs from "walk- 
in" customers and reservation inputs, and uses AOS table 
state information to determine table allocation. Once a 
5 table is available, the RMS function may utilize various 
methods of calling waiting customers. The RMS may 
optionally implement a mapping application that highlights 
available tables on a restaurant map and allows customers 
to seat themselves. This mapping application also depicts 
10 the restaurant layout, identifies tables and booths, table 
numbers, etc. so that walk-in customers can specify 
preference for a particular table. 



The Reception Management System function, 28 in 
Figures 3 and 4, also runs on the RAS Compute Server that 
hosts the Automated Ordering System function 

Figure 21 depicts the Reception Management System 
architecture. 

Reception Display 

The Reception Display is located in the restaurant's 
reception area. It is the primary point of interaction for 
customers arriving at a full restaurant. The Reception 
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Display consists of a large touch screen display and a 
wireless communications interface. It may also contain a 
sound card and a speaker. 

5 Figure 22 depicts the Table Wait Time Summary screen 

provided to customers at the Reception Display. This 
preferred Reception Display uses colors to reflect expected 
wait times. For example, red may be associated with tables 
with the longest wait times and green may be associated 
10 with those with the shortest wait times. The summary 
screen provides, at a glance, the expected wait times 
associated with tables of various sizes. This wait time 
information is based on data from the AOS active table 
state information as described below (in RMS Function 
15 section) . 



If a potential customer decides he/she wants to wait 
for a table, he can press the "reserve" button, 29 in 
Figure 22, and bring up the Reception Display's Join Queue 
20 screen depicted in Figure 23, and enter his/her name as 
indicated. The Reception Display provides a "soft 
keyboard" through which customers may enter name 
information into the gueue. 
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Reservation Display 

Many restaurants have existing systems that allow for 
call-in reservations or manually handle call-in 
reservations via paper schedule. The Reception Management 
5 System provides a dedicated display interface that allows 
restaurant staff to accept call-in reservations and enter 
them into a graphical scheduling interface. 

The Reservation Display is accessible to the 
10 restaurant staff who receive phone-in reservations. The 
Reservation Display consists of a touch sensitive display 
and a wireless communications interface. 

The Reservation Display shows the same information 
that is shown on the Reception Display and additionally 
provides access to a scheduling function that allows the 
staff to enter reservations that have been phoned-in. This 
call-in reservation information is stored in the RMS data 
store on the RAS compute server. When new customers arrive 
and interface with the Reception Display, the RMS 
incorporates call-in reservation information into its 
scheduling and table assignments by blocking off tables 
during the times for which they are reserved. If the party 
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with the reservation does not show up in a - prescribed time 
frame, the RMS function automatically releases the table 
for availability. 

Information from the Reception Display is useful to 
the restaurant reservation staff because it provides data 
on the short term availability of tables for those phone- 
ins that request relatively immediate reservations. 

RMS Function 

The RMS function resides on the RAS Compute server 
uses the AOS function's data store of active table state 
data. For example, the RMS function uses the following 
information from the AOS function to determine the expected 
wait time for an occupied table to clear. 

1 . Number of persons at table 

2. Appetizers ordered? 

3. Main course ordered? 

4. Deserts ordered? 

5. Bill requested? 

6. Bill payment status 
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The RMS function considers this information and then 
may add a factor for the time needed to clean and prepare 
the table for the next party. 

5 The RMS function is primarily a scheduling system. 

The RMS system receives input from the Reservation Display 
at which restaurant staff input reservation requests from 
customers who call in advance. These call-in reservations 
block off windows of time for tables of a specific size in 
10 the restaurant's schedule. The RMS function also receives 
input from the Reception Display at which customers without 
reservations make immediate requests for a table of a 
specific size. The RMS function uses these inputs, 
scheduling algorithms, and the AOS function's table state 
15 information to estimate wait times for tables. The RMS 
functions algorithms are intelligent enough to assign a 
table for 4 to a party of 2 or 3, a table for 6 to a party 
of 4 or 5, and so on based on current table utilization 
rate rates. 
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These estimated wait times are displayed on the 
Reception Display for entering customers. Immediate table 
requests made at the Reception Display block off short-term 
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time windows that affect call-in reservations. The 
restaurant staff accepting call-in reservations is provided 
the information from the Reception Display at the 
Reservation Display. Hence, call-in reservations limit 
table availability for walk-ins at the Reception Display 
and walk-ins entering table queues at the Reception display 
limit short-term table availability for those calling in. 

Once a table becomes available, as identified by the 
bill being settled and the party leaving, the service staff 
can access the Table Status Display and interact with a 
touch screen function that sets the table status to 
"Available". This table status is then passed to the RMS 
function. The RMS function may call the first party in the 
queue that can be seated at that table size using various 
methods. First, a recording may call "Table for party of 4 
ready" repeatedly for a predetermined period of time and 
may flash the name of party on the screen (this also 
assists the service staff in identifying the party) . 
Alternatively, the RMS function may interface with existing 
flasher/buzzer devices that customers carry with them until 
their tables are ready. The RMS function may be notified 
that the party has been seated when the table registers an 
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K-Menu at the table or when an indication is made by the 
service staff on the Reservation Display. A member of the 
service staff may accompany the party to their table. If a 
Party does not arrive in a predetermined timeframe, the 
5 RMS system may move on the next party in the queue. 

The Reception Management System may aiso provide an 
optional mapping application that displays the floor and 

table layout of the dinina area m. ,, 

inmg area. Thas allows new customers 

10 to determine the location of tables and to specify 

preferences for specific tables. When a table becomes 
available, customers can determine where to go thereby 
eliminating the need for the service staff to accompany 
them. The mapping application also displays the number of 
15 the available table. Each table at a RAS equipped 

restaurant may also have a numeric display to facilitate 
finding the table. Fina l ly , i£ the table ± . ^ 
a TCU, and the RMS function receives notice that a table 
has become available and calls the waiting party, it may 
20 send a signal to the table's TCU unit, to emit a signal 

such as a pattern of light , la shes thereby making it easier 
to find for the diners. 
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RMS Process Flow Concept 

Figure 24 depicts the process a "walk-in" customer 
entering a restaurant would follow to make a reservation 
after deciding that he wants to wait for a table. Once the 
5 RMS identifies that a table has become available for a 

party of a particular size, various methods of calling the 
party may be implemented including using voice calling or 
interfacing to a buzzer system as described above. 

10 Once the party has been identified, a member of the 

common service staff may direct the party to the table or a 
mapping application may be used to extend the RMS 
functionality as described above. 
Customer Personalization System 

15 

The Customer Personalization System addresses concerns 
that the RAS may be impersonal and that it removes the 
personalization that a waiter can provide. The CPS 
function residing on the restaurant's RAS compute server 
20 maintains a data store of customer IDs of those who choose 
to participate in the CPS program. CPS provides a high 
level of meal behavior tracking and provides benefits to 
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RAS restaurant customers at a level that is not possible by 
individual waiters. 

The core of the CPS operates centrally at the RAS 
5 Central Service Center and thereby can track meal patterns 
and preferences for customers based on a customer ID over 
all RAS equipped restaurants. The CPS can then apply 
focused advertising via the E-Menu and discount benefits 
automatically to patrons that exhibit certain dining 
10 patterns or provide a certain level of patronage. The CPS 
thereby provides a powerful means by which the restaurant 
industry can attract and retain more patrons and provide 
advertising and marketing channels. 

15 The Automated Ordering System function maintains data 

on customer dining patterns such as types of meals ordered, 
patronage frequency, etc. in its data store. This 
information can also be shared with information from other 
RAS restaurants and compiled at the RAS Central Service 
20 Center over an Internet or dial up link. Hence, customer 
specific information can be collected across many RAS 
equipped restaurants. This information can be used to 
personalize service for specific customers. For example, a 
customer who shows a pattern of consuming kosher meals can 
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be sent specific recommendations and meal suggestions or 
can be sent specific hyperlinks to advertiser's website to 
internet sites for kosher restaurants or services. 
Customers may be identified by a specific RAS customer ID. 
5 Figure 25 depicts the CPS Architecture. 

CPS funct ion on Restaurant RAS Compute Server 

When CPS participants enter a RAS equipped restaurant, 
they may walk up to a Payment Station and access the CPS 
10 function. In the CPS function, they may enter their 
customer ID and table number. The CPS function on the 
restaurant's RAS compute server then accesses the 
customer's data from the RAS Central server at the RAS 
Central Service facility. The primary data retrieved are: 
15 1) the customer's membership level which indicates a level 
of patronage of money spent at RAS restaurants and 2) any 
preferences for food types (kosher, vegetarian, etc) . 
Other data may also be retrieved. Based on this 
information, the restaurant's CPS function may focus 
20 specific advertising to the E-Menu's at the customer's 
table or call attention to specific items that may be of 
interest. Additionally, the RAS system may have 
arrangements with special interest organizations and 
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marketers, etc. that may want to direct focused advertising 
to specific groups via the E-Menu platform. This may 
provide an additional revenue stream for the restaurant 
industry. Additionally, when the customer initiates the 
bill payment process, the AOS function queries the CPS 
function to see if the table qualifies for discounts. The 
CPS function will use the customer's patronage level to 
determine a discount level and forward this to the AOS 
function's billing process. The discounted bill is then 
sent to the Payment Station. 

CPS Function on RAS Central Server 

The CPS function on the RAS central server maintains 
the central repository of all frequent RAS restaurant diner 
information such as: 

• Customer IDs 

• Patronage level 

• Cuisine preference 

Other data may also be maintained. The RAS central 
server« receives this information regularly from RAS 
equipped restaurants via the Internet or dial up means - 
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either on an event-by-event basis or via daily or weekly 
uploads. The RAS Central server dispenses this information 
to a RAS restaurant when a frequent CPS customer enters his 
customer ID at a Payment Station and the restaurant's RAS 
5 compute server makes a request to the RAS central server. 
The RAS Central server then downloads the customer 
patronage level and cuisine preference information to the 
restaurant's RAS compute server via the Internet or dial up 
means. This information is then used for specific 
) advertising/marketing activities via the E-Menu and for 
applying discounts as described above. 



As described in the previous section, there may be 
customers who decide to proactively participate in and 
become members of the CPS frequent diner function. These 
customers are assigned a customer ID. However, there may 
be customers who choose not to proactively participate in 
the CPS function or who do not know of it. These customers 
may frequently dine at RAS restaurants. To provide an 
automated benefit to these customers, the CPS function on 
the RAS central server tracks bill payment by credit card 
number. Each time a customer dines and makes a credit card 
payment, the credit card information, meals ordered, etc. 
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information is stored on the restaurant's RAS Compute 
server as described in the AOS function section. This 
information is regularly uploaded to the RAS central 
server. The RAS central server has intelligent processes 
that scan through this data and can identify customers 
based on credit card numbers, which may qualify for 
specific discounts based on their dining frequency. When 
the RAS Central server identifies that someone qualifies 
for a discount, it performs a broadcast download of the 
credit card information to the RAS compute servers of all 
RAS equipped restaurants. The RAS compute servers of the 
restaurants maintain this frequent diner credit card number 
in a table within its data store. When that specific 
customer dines at a RAS restaurant and swipes his credit 
card during the payment process, the AOS function queries 
the CPS function to see if the credit card is in the 
frequent diner list. If it is, the CPS function returns a 
discount value as suggested by the RAS central server. 

Hence, this system offers a novel method of granting 
frequent diner benefits completely automatically with no 
customer involvement or intervention. 
CPS Process Flow 
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Figure 26 depicts the process flow associated with the 
CPS function for a customer who participates in the CPS 
function and has a customer ID. Note that for a customer 
who does not participate in the CPS function, as the 
customer swipes his credit card to pay for their meal, the 
CPS function would automatically detect the customer's 
dining frequency and habits and apply the appropriate 
benefits, such as discounts. 

E-Menu Screens 

Figure 27 depicts a sample home screen. This is the 
first screen that would be presented on an E-Menu to a 
diner. It provides the choice of viewing the menu or 
accessing the Internet. 

Figure 28 depicts the main menu screen from which 
diners can navigate into sub menus for particular meal 
courses . 

Figure 29 depicts the home screen for Internet 
surfing. A diner can choose pre-defined sites thereby 
eliminating the need to enter an URL address or can open a 
browser and type a specific address. 
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Figure 30 depicts a pop-up detailed description screen 
that provides more information on a particular menu choice. 

Figure 31 depicts a sub menu for a particular meal 
5 course e.g., wine list. Note that a running "Your Order- 
screen, 30, is provided that maintains a list of items the 
diner has placed on his order. When ordering off a 
submenu, the touch-screen selection provides a vast 
improvement over prior automated ordering system that 
) required diners to correctly enter the codes or numbers 

that are associated with the desired item. The requirement 
to enter such designators only provides a chance to make an 
error, and unnecessarily tests the diner on information 
(e.g., the codes) known better to the restaurant staff. 
This testing can detract from the pleasure and purpose of 
restaurant dining. 

Figure 32 depicts the Internet access screen in which 
diners can type in a specific URL to visit a specific web 
site using a "soft" keyboard 19. 
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Figure 33 depicts the split screen functionality of 
the E-Menu allowing 2 courses, or sub-menus, to be viewed 
simultaneously as with a traditional hard copy menu. 

Figure 34 shows a photo screen of a menu item, 
provided according to a preferred embodiment of the E-menu 
of the present invention. 



Figure 35 depicts the Filter Display function 39 that 
allows diners to specify categories of menu items that 
should be displayed according to various filters. 

The Restaurant Automation System increases the 
efficiency of the dining experience and reduces the amount 
of time customers unnecessarily occupy a table waiting for 
service. For the restaurant, this provides the benefit of 
turning tables more quickly and thereby increasing revenue. 
Operational cost is reduced because many front-end 
processes are automated. Customers are provided greater 
control over their dining experience because they get what 
they want, when they want it. For example, appetizers and 
the main course can be timed by the customer to ensure that 
both courses arrive hot when the customer is ready for 
them. Bill payment can be made at anytime without having 
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to rely on the arrival of the check. This ultimately 
eliminates variation in dining times and provides a 
predictable, controlled dining experience. Customers can 
tailor their meal to the exact time that is appropriate for 
their schedule. 



Finally, the Restaurant Automation System provides a 
more comfortable dining experience by eliminating 
sometimes -intrusive visits by waiters/waitresses for 
satisfaction inquiries, water refills, plate removal, etc. 
The Restaurant Automation System puts the customer in 
complete control of when service personnel arrive and for 
what purpose. 

There has thus been shown and described a novel 
Restaurant Automation System which fulfills all the object! 
and advantages sought therefore. Many changes, 
modifications, variations and other uses and applications 
of the subject invention will, however, become apparent to 
those skilled in the art after considering this 
specification and the accompanying drawings which disclose 
the preferred embodiments thereof. All such changes, 
modifications, variations and other uses and applications 
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which do not depart from the spirit and scope of the 
invention are deemed to be covered by the invention, which 
is to be limited only by the claims which follow. 
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